Network Working Group 
Request for Comments: 


SNMPv2 Working Group 


1904 J. Case 


Obsoletes: 1444 SNMP Research, Inc. 
Category: Standards Track K. McCloghrie 
Cisco Systems, Inc. 

M. Rose 

Dover Beach Consulting, Inc. 


S. Waldbusser 
International Network Services 
January 1996 


Conformance Statements for Version 2 of the 
Simple Network Management Protocol (SNMPv2) 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Table of Contents 


Its = ENE LOCUCES OM. uS O tesa) Scot h ine ek tee onshore a E ethan MO Ed la Res utr 2, 
Lol A Note con’ Terminology see odes eee. ese be io! AE rae an wees 2 eS 3 
2%. DEPINTELONSS Sraa i vessel oe A OE A da ee ete Se ee ais eee Shee eGo 3 
251. ARE OBJECT =GROUP MaC O -aes steers so ea sewn o -ah food alah Sie dreigele Beets, wish a 3 
22° The: NOLIFICAT.ION=GROUP macro Sanan a i eee ee ee ee te 4 
233 The. MODULE=COMPLEANCE MaC O: ceren a cote Shee aie hee ee Seat 5 
24: The: AGENT-CAPABILET FES: MAC O: ssid oleh ele acd YO ole da Sw ere ae ¥ © Weds 7 
3° Mapping: Of the OBUECT=GROUPMACIO? safen eis ou onthe Slee eave ad ales 9 
3.1. Mapping of the. OBJECTS Clause: oc kee ete Se ee ee See ee cee e's 10 
3.2 Mapping of -the STATUS Clase sa eecie ceed eee see eee ua Ee 10 
3..3--Mapping of. the DESCRIPTION: Clause. susene es es Sees ee Se are ee 10 
34- Mapping of- -the REFERENCE Clause: .2o.c cis hese erect g soso eg bed See Ged tastes 10 
35 Mapping: of: the- /OBJECT-GROUP: value. manoesa e Guanes oe Seek eve eae 2 ee 10 
BwOs USAGE CE RAMpAcS is ah A te cat tah tO cece bh tte A sok PIAA as te ad E Sus cee ete. 8 11 
4. Mapping of the NOTIFICATION-GROUP macro .............-.-2000- 11 
4.1 Mapping of the NOTIFICATIONS clause ................----200- LT 
42 Mapping. of the- STATUS Clause: sesia eo so n E eee ote Ses eee ee aie 
4.3 Mapping of the DESCRIPTION clause ..............----- ee eeee 12 
4.4 Mapping of the REFERENCE clause .............- ++ eee eee eee eee 12 
4.5 Mapping of the NOTIFICATION-GROUP value .........2eceeeeeeee 12 
43,6; US age Example esur nee al one eee ea eyed a Gen S78 Bathe E Sele ets Tare Ve ess 12 
5. Mapping of the MODULE-COMPLIANCE macro .......eece cece eee eee 12 
5s 1 Mapping: of the STATUS -CLauUse) 2 yee escae lee raa aeaa e Bie ee ww ee ot 1.3 
SNMPv2 Working Group Standards Track [Page 1] 


RFC 19 


1 
2 
3 
4 
5 
5 
5 
s3 
5 
3 
5 
5 
5 
6 
7 


FPRFPO WMAYTAAADAAAAAIAAAGAIAAACAGAVAGRDUNUNATHKAAAIIooo vo 


O. 
Í 


Ta In 


DOS SS eae D 


04 


Usage Examp 


Mapping of 
Mapping of 
Mapping of 
Mapping of 
Mapping of 


Mapping 
Mapping 
Mapping 
Mapping 
Mapping 
Mapping 
apping of 

Usage Examp 


NUP WN E 


eal 
<2 
Bea 
Ae 
2. 
<23 
Bae 
eae 
M 


Extending an Information Module 
.1 Conformance Groups 
-2 Compliance Definitions 
.3 Capabilities Definitions 
Security Considerations 
Editor’s Address 
Acknowledgements 


References 


troduction 


Conformance Statements for SNMPv2 


le 


of 
of 
of 
of 
of 
of 
the 
le 


.2 Mapping of the DESCRIPTION clause 
.3 Mapping of the REFERENCE clause 
.4 Mapping of the MODULE clause 
1 Mapping of the MANDATORY-GROUPS clause 
2 Mapping of the GROUP clause 
3 Mapping of the OBJECT clause 
.3.1 Mapping of the SYNTAX clause 
3.2 Mapping of the WRITE-SYNTAX clause 
3.3 Mapping of the MIN-ACCESS clause 
-4 Mapping of the DESCRIPTION clause 
Mapping of the MODULE-COMPLIANCE value 


January 1996 


E E AREER 13 
SN ee eo eee 13 
Eee Wares aera 13 
Bessa a E A fa vers 13 
E TE jereet nee 14 
drs) Regis, Sidas E se haee 14 
E E a ANE 14 
TE ote A ea set fo a 15 
NEREDA AE AEA LS 
Sic guib esas oo Srangecgris E 15 
Srend Seer eis ATT Sie eis 15 


Sisk gto A geal oe go's lotta E E EE E T shaj leer E at gue A EA 16 


Mapping of the AGENT-CAPABILITIES macro 
the PRODUCT-RELEASE clause 
the STATUS clause 
the DESCRIPTION clause 
the REFERENCE clause 
the SUPPORTS clause 
Mapping of the INCLUDES clause 
Mapping of the VARIATION clause 
SYNTAX clause ........... 
WRITE-SYNTAX clause ..... 
ACCESS “GLausSe@s su ere dee ees 


the 
the 
the 
the 
the 
the 


CREATION-REQUIRES clause 


DEFVAL clause ........... 


aa ee ua e a wie S 16 
SPP eg Ga SET ae 9 oN 17 
SAS UNE Sud VISES 17 
SSS s aR TRE Spee 17 
gis See ge eadee Goes eae 17 
So E E ves S 18 
Ta A aa E aa 18 
ATE EAE OAA 18 
r E ANE Mie E 18 
E E REA E 18 
EEEE ER Se TEA 19 
ae BN Sab ae BR caren a eng 19 
Sie PIS GP EE Sg eS 20 
ee a eee ee 20 
SE RE Rk Het ase 20 


Stadt es One aba. a aye) ads Genta akens aad RA sh ey E Ea E ere Senta eer aee S 20 


Seep ih a ae E EE ho 22 
aS Nate forede. 3 She @ Ste. 8 22 
Biss joel oiverts, eens eve cee 22 
E eG have vee ace are od 22 
RE E Aa te 23 


dates dated SN. a hak e he a kM E A ER E EE 23 
AT EE RNE Gr a Gs E S E S 23 


E Tarzan E Se 0 E E E a E a a a A E a S 24 


A management system contains: several (potentially many) nodes, each 
with a processing entity, termed an agent, which has access to 


management instrumentation; 
management protocol, 
the agents and management stations. 


at least one management station; and, a 
used to convey management information between 
Operations of the protocol are 


carried out under an administrative framework which defines 
authorization, access control, 


aut 


hentication, 
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Management stations execute management applications which monitor and 
control managed elements. Managed elements are devices such as 
hosts, routers, terminal servers, etc., which are monitored and 
controlled via access to their management information. 


Management information is viewed as a collection of managed objects, 
residing in a virtual information store, termed the Management 
Information Base (MIB). Collections of related objects are defined 
in MIB modules. These modules are written using a subset of OSI’s 
Abstract Syntax Notation One (ASN.1) [1], termed the Structure of 
Management Information (SMI) [2]. 


It may be useful to define the acceptable lower-bounds of 
implementation, along with the actual level of implementation 
achieved. It is the purpose of this document to define the notation 
used for these purposes. 


1.1. A Note on Terminology 


For the purpose of exposition, the original Internet-standard Network 
Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD 
15), and 1212 (STD 16), is termed the SNMP version 1 framework 
(SNMPv1). The current framework is termed the SNMP version 2 
framework (SNMPv2). 


2. Definitions 
SNMPv2-CONF DEFINITIONS ::= BEGIN 
-—- definitions for conformance groups 


OBJECT-GROUP MACRO ::= 
BEGIN 
TYPE NOTATION ::= 
ObjectsPart 
"STATUS" Status 
"DESCRIPTION" Text 
ReferPart 


VALUE NOTATION ::= 
value (VALUE OBJECT IDENTIFIER) 


ObjectsPart ::= 
"OBJECTS" "{" Objects "}" 
Objects = 
Object 
| Objects "," Object 
Object ::= 
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value (Name ObjectName) 


Status ::= 
"current" 
| "deprecated" 
| "obsolete" 
ReferPart ::= 


"REFERENCE" Text 
| empty 


—— uses the NVT ASCII character set 
Text os LLES LES 1 E string LLES LES 1 E 
END 


—- more definitions for conformance groups 


NOTIFICATION-GROUP MACRO ::= 
BEGIN 
TYPE NOTATION ::= 
NotificationsPart 
"STATUS" Status 
"DESCRIPTION" Text 
ReferPart 


VALUE NOTATION ::= 
value (VALUE OBJECT IDENTIFIER) 


NotificationsPart ::= 
"NOTIFICATIONS" "{" Notifications "}" 


Notifications ::= 

Notification 

Notifications "," Notification 
Notification ::= 

value (Name NotificationName) 
Status ::= 

"current" 

"deprecated" 

"obsolete" 
ReferPart ::= 


"REFERENCE" Text 
| empty 


-- uses the NVT ASCII character set 
Text = Two string Two 
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—- definitions for compliance statements 


MODULE-COMPLIANCE MACRO ::= 


BEGIN 


TYPE NOTATION ::= 


"STATUS" Status 
"DESCRIPTION" Text 
ReferPart 
ModulePart 


VALUE NOTATION ::= 


Status ::= 


ReferPart 


ModulePart 


Modules 


Module ::= 


ModuleName 


value (VALUE OBJECT IDENTIFIER) 


"current" 
| "deprecated" 
| "obsolete" 


"REFERENCE" Text 
empty 


Modules 
| empty 


Module 
| Modules Module 


-- name of module -- 
"MODULE" ModuleName 
MandatoryPart 
CompliancePart 


modulereference ModuleIdentifier 
—- must not be empty unless contained 
-- in MIB Module 
| empty 


ModuleIdentifier ::= 


value (ModuleID OBJECT IDENTIFIER) 
| empty 


MandatoryPart ::= 


"MANDATORY-GROUPS" "{" Groups "}" 
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| empty 


Groups 
Group 
Groups "," Group 


Group 
value (Group OBJECT IDENTIFIER) 


CompliancePart ::= 
Compliances 
| empty 


Compliances ::= 
Compliance 
| Compliances Compliance 
Compliance ::= 
ComplianceGroup 
| Object 


ComplianceGroup ::= 
"GROUP" value(Name OBJECT IDENTIFIER) 
"DESCRIPTION" Text 


Object 
"OBJECT" value (Name ObjectName) 
SyntaxPart 
WriteSyntaxPart 
AccessPart 
"DESCRIPTION" Text 


—- must be a refinement for object’s SYNTAX clause 
SyntaxPart ::= 
"SYNTAX" type (SYNTAX) 
| empty 


—- must be a refinement for object’s SYNTAX clause 
WriteSyntaxPart ::= 
"WRITE-SYNTAX" type (WriteSYNTAX) 
| empty 


AccessPart ::= 
"MIN-ACCESS" Access 
| empty 
Access ::= 
"not-accessible" 
"accessible-for-notify" 
"read-only" 
| "read-write" 
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"read-create" 


—— uses the NVT ASCII character set 
Text “= Two string woe 
END 


-- definitions for capabilities statements 


AGENT-CAPABILITIES MACRO ::= 
BEGIN 
TYPE NOTATION ::= 

"PRODUCT-RELEASE" Text 
"STATUS" Status 
"DESCRIPTION" Text 
ReferPart 
ModulePart 


VALUE NOTATION ::= 
value (VALUE OBJECT IDENTIFIER) 


Status ::= 
"current" 
| "obsolete" 
ReferPart ::= 
"REFERENCE" Text 
| empty 
ModulePart ::= 
Modules 
| empty 
Modules ::= 
Module 
| Modules Module 
Module ::= 
-- name of module -- 
"SUPPORTS" ModuleName 
"INCLUDES" "{" Groups "}" 
VariationPart 
ModuleName ::= 
identifier ModuleIdentifier 
ModulelIdentifier ::= 
value (ModuleID OBJECT IDENTIFIER) 
| empty 
Groups ::= 
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Group 
Groups "," Group 
Group ::= 
value (Name OBJECT IDENTIFIER) 
VariationPart ::= 
Variations 
| empty 
Variations ::= 
Variation 
| Variations Variation 
Variation ::= 


ObjectVariation 
| NotificationVariation 


NotificationVariation ::= 
"VARIATION" value (Name NotificationName) 
AccessPart 
"DESCRIPTION" Text 


ObjectVariation ::= 
"VARIATION" value (Name ObjectName) 
SyntaxPart 
WriteSyntaxPart 
AccessPart 
CreationPart 
DefValPart 
"DESCRIPTION" Text 


—- must be a refinement for object’s SYNTAX clause 
SyntaxPart ::= 
"SYNTAX" type (SYNTAX) 
| empty 


—- must be a refinement for object’s SYNTAX clause 


WriteSyntaxPart ::= 
"WRITE-SYNTAX" type (WriteSYNTAX) 
| empty 


AccessPart ::= 
"ACCESS" Access 
| empty 


Access 
"not-implemented" 
-—- only "not-implemented" for notifications 
"accessible-for-notify" 
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| "read-only" 

| "read-write" 

| "read-create" 

-- following is for backward-compatibility only 
| "write-only" 


CreationPart ::= 
"CREATION-REQUIRES" "{" Cells "}" 
| empty 
Cells = 
Cell 
Cells "," Cell 
Cell = 
value (Cell ObjectName) 
DefValPart ::= 


"DEFVAL" "{" value (Defval ObjectSyntax) "}" 
| empty 


-- uses the NVT ASCII character set 
Text Cea Two string Two 


Mapping of the OBJECT-GROUP macro 


For conformance purposes, it is useful to define a collection of 
related managed objects. The OBJECT-GROUP macro is used to define 
each such collection of related objects. It should be noted that the 
expansion of the OBJECT-GROUP macro is something which conceptually 
happens during implementation and not during run-time. 


To "implement" an object, a SNMPv2 entity acting in an agent role 
must return a reasonably accurate value for management protocol 
retrieval operations; similarly, if the object is writable, then in 
response to a management protocol set operation, a SNMPv2 entity must 
accordingly be able to reasonably influence the underlying managed 
entity. If a SNMPv2 entity acting in an agent role can not implement 
an object, the management protocol provides for the SNMPv2 entity to 
return an exception or error, e.g, noSuchObject [4]. Under no 
circumstances shall a SNMPv2 entity return a value for objects which 
it does not implement -- it must always return the appropriate 
exception or error, as described in the protocol specification [4]. 
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3.1. Mapping of the OBJECTS clause 


The OBJECTS clause, which must be present, is used to name each 
object contained in the conformance group. Each of the named objects 
must be defined in the same information module as the OBJECT-—GROUP 
macro appears, and must have a MAX-ACCESS clause value of 
"accessible-for-notify", "read-only", "read-write", or "read-create". 


It is required that every object defined in an information module 
with a MAX-ACCESS clause other than "not-accessible" be contained in 
at least one object group. This avoids the common error of adding a 
new object to an information module and forgetting to add the new 
object to a group. 


3.2. Mapping of the STATUS clause 


The STATUS clause, which must be present, indicates whether this 
definition is current or historic. 


The values "current", and "obsolete" are self-explanatory. The 
"deprecated" value indicates that the definition is obsolete, but 
that an implementor may wish to support the group to foster 
interoperability with older implementations. 


3.3. Mapping of the DESCRIPTION clause 


The DESCRIPTION clause, which must be present, contains a textual 
definition of that group, along with a description of any relations 
to other groups. Note that generic compliance requirements should 
not be stated in this clause. However, implementation relationships 
between this group and other groups may be defined in this clause. 


3.4. Mapping of the REFERENCE clause 


The REFERENCE clause, which need not be present, contains a textual 
cross-reference to a group defined in some other information module. 
This is useful when de-osifying a MIB module produced by some other 
organization. 


3.5. Mapping of the OBJECT-GROUP value 


The value of an invocation of the OBJECT-GROUP macro is the name of 
the group, which is an OBJECT IDENTIFIER, an administratively 
assigned name. 
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3.6. Usage Example 


The SNMP Group [3] 


snmpGroup OBJECT-GROUP 


OBJECTS { 


snmpiInPkts, 


is described: 


snmpInBadVersions, 
snmpInASNParseErrs, 
snmpBadOperations, 
snmpSilentDrops, 
snmpProxyDrops, 
snmpEnableAuthenTraps } 
STATUS current 
DESCRIPTION 
"A collection of objects providing basic instrumentation and 
control of an SNMPv2 entity." 
::= { snmpMIBGroups 8 } 


According to this invocation, the conformance group named 


{ snmpMIBGroups 8 } 


contains 7 objects. 


4. Mapping of the 


For conformance 
notifications. 


should be noted that the 


something which 
during run- 


time. 


purposes, 
The NOTIFICATION-GROUP macro serves this purpose. It 


NOTIFICATION-GROUP macro 


it is useful to define a collection of 


expansion of the NOTIFICATION-GROUP macro is 


conceptually happens during implementation and not 


4.1. Mapping of the NOTIFICATIONS clause 


The NOTIFICATIONS clause, 


which must be present, is used to name each 


notification contained in the conformance group. Each of the named 
notifications must be defined in the same information module as the 
NOTIFICATION-GROUP macro 


4.2. Mapping 


The STATUS 
definition 


The values 


of the STATUS 


clause, which 
is current or 


"Current", and 


appears. 
clause 


must be present, indicates whether this 
historic. 


"obsolete" are self-explanatory. The 


"deprecated" value indicates that the definition is obsolete, but 
that an implementor may wish to support the group to foster 
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interoperability with older implementations. 
4.3. Mapping of the DESCRIPTION clause 


The DESCRIPTION clause, which must be present, contains a textual 
definition of the group, along with a description of any relations to 
other groups. Note that generic compliance requirements should not 
be stated in this clause. However, implementation relationships 
between this group and other groups may be defined in this clause. 


4.4. Mapping of the REFERENCE clause 


The REFERENCE clause, which need not be present, contains a textual 
cross-reference to a group defined in some other information module. 
This is useful when de-osifying a MIB module produced by some other 
organization. 


4.5. Mapping of the NOTIFICATION-GROUP value 
The value of an invocation of the NOTIFICATION-GROUP macro is the 


name of the group, which is an OBJECT IDENTIFIER, an administratively 
assigned name. 


4.6. Usage Example 
The SNMP Basic Notifications Group [3] is described: 


snmpBasicNotificationsGroup NOTIFICATION-GROUP 
NOTIFICATIONS { coldStart, authenticationFailure } 


STATUS current 

DESCRIPTION 
"The two notifications which an SNMPv2 entity is required to 
implement." 


::= { snmpMIBGroups 7 } 
According to this invocation, the conformance group named 
{ snmpMIBGroups 1 } 
contains 2 notifications. 
5. Mapping of the MODULE-COMPLIANCE macro 
The MODULE-COMPLIANCE macro is used to convey a minimum set of 
requirements with respect to implementation of one or more MIB 
modules. It should be noted that the expansion of the MODULE- 


COMPLIANCE macro is something which conceptually happens during 
implementation and not during run-time. 
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A requirement on all "standard" MIB modules is that a corresponding 
MODULE-COMPLIANCE specification is also defined, either in the same 
information module or in a companion information module. 


5.1. Mapping of the STATUS clause 


The STATUS clause, which must be present, indicates whether this 
definition is current or historic. 


The values "current", and "obsolete" are self-explanatory. The 
"deprecated" value indicates that the specification is obsolete, but 
that an implementor may wish to support that object to foster 
interoperability with older implementations. 


5.2. Mapping of the DESCRIPTION clause 


The DESCRIPTION clause, which must be present, contains a textual 
definition of this compliance statement and should embody any 
information which would otherwise be communicated in any ASN.1 
commentary annotations associated with the statement. 


5.3. Mapping of the REFERENCE clause 


The REFERENCE clause, which need not be present, contains a textual 
cross-reference to a compliance statement defined in some other 
information module. 


5.4. Mapping of the MODULE clause 


The MODULE clause, which must be present, is repeatedly used to name 
each MIB module for which compliance requirements are being 
specified. Each MIB module is named by its module name, and 
optionally, by its associated OBJECT IDENTIFIER as well. The module 
name can be omitted when the MODULE-COMPLIANCE invocation occurs 
inside a MIB module, to refer to the encompassing MIB module. 


5.4.1. Mapping of the MANDATORY-GROUPS clause 


The MANDATORY-GROUPS clause, which need not be present, names the one 
or more object or notification groups within the correspondent MIB 
module which are unconditionally mandatory for implementation. Ifa 
SNMPv2 entity acting in an agent role claims compliance to the MIB 
module, then it must implement each and every object and notification 
within each conformance group listed. That is, if a SNMPv2 entity 
returns a noSuchObject exception in response to a management protocol 
get operation [4] for any object within any mandatory conformance 
group for every MIB view, or if the SNMPv2 entity cannot generate 
each notification listed in any conformance group under the 
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appropriate circumstances, then that SNMPv2 entity is not a 
conformant implementation of the MIB module. 


5.4.2. Mapping of the GROUP clause 


The GROUP clause, which need not be present, is repeatedly used to 
name each object and notification group which is conditionally 
mandatory or unconditionally optional for compliance to the MIB 
module. A group named in a GROUP clause must be absent from the 
correspondent MANDATORY-GROUPS clause. 


Conditionally mandatory groups include those which are mandatory only 
if a particular protocol is implemented, or only if another group is 
implemented. A GROUP clause’s DESCRIPTION specifies the conditions 
under which the group is conditionally mandatory. 


A group which is named in neither a MANDATORY-GROUPS clause nor a 
GROUP clause, is unconditionally optional for compliance to the MIB 
module. 


5.4.3. Mapping of the OBJECT clause 


The OBJECT clause, which need not be present, is repeatedly used to 
name each MIB object for which compliance has a refined requirement 
with respect to the MIB module definition. The MIB object must be 
present in one of the conformance groups named in the correspondent 
MANDATORY-GROUPS clause or GROUP clauses. 


By definition, each object specified in an OBJECT clause follows a 
MODULE clause which names the information module in which that object 
is defined. Therefore, the use of an IMPORTS statement, to specify 
from where such objects are imported, is redundant and is not 
required in an information module. 


5.4.3.1. Mapping of the SYNTAX clause 
The SYNTAX clause, which need not be present, is used to provide a 
refined SYNTAX for the object named in the correspondent OBJECT 
clause. Note that if this clause and a WRITE-SYNTAX clause are both 
present, then this clause only applies when instances of the object 


named in the correspondent OBJECT clause are read. 


Consult Section 9 of [2] for more information on refined syntax. 
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5.4.3.2. Mapping of the WRITE-SYNTAX clause 
The WRITE-SYNTAX clause, which need not be present, is used to 
provide a refined SYNTAX for the object named in the correspondent 
OBJECT clause when instances of that object are written. 
Consult Section 9 of [2] for more information on refined syntax. 


5.4.3.3. Mapping of the MIN-ACCESS clause 


The MIN-ACCESS clause, which need not be present, is used to define 
the minimal level of access for the object named in the correspondent 


OBJECT clause. If this clause is absent, the minimal level of access 
is the same as the maximal level specified in the correspondent 
invocation of the OBJECT-TYPE macro. If present, this clause must 


not specify a greater level of access than is specified in the 
correspondent invocation of the OBJECT-TYPE macro. 


The level of access for certain types of objects is fixed according 
to their syntax definition. These types include: conceptual tables 
and rows, auxiliary objects, and objects with the syntax of 
Counter32, Counter64 (and possibly, certain types of textual 
conventions). A MIN-ACCESS clause should not be present for such 
objects. 


An implementation is compliant if the level of access it provides is 
greater or equal to the minimal level in the MODULE-COMPLIANCE macro 
and less or equal to the maximal level in the OBJECT-TYPE macro. 


5.4.4. Mapping of the DESCRIPTION clause 


The DESCRIPTION clause must be present for each use of the GROUP or 
OBJECT clause. For an OBJECT clause, it contains a textual 
description of the refined compliance requirement. For a GROUP 
clause, it contains a textual description of the conditions under 
which the group is conditionally mandatory or unconditionally 
optional. 


5.5. Mapping of the MODULE-COMPLIANCE value 


The value of an invocation of the MODULE-COMPLIANCE macro is an 
OBJECT IDENTIFIER. As such, this value may be authoritatively used 
when referring to the compliance statement embodied by that 
invocation of the macro. 
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5.6. Usage Example 


The compliance statement contained in the (hypothetical) XYZv2-MIB 
might be: 


xyzMIBCompliance MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 
"The compliance statement for XYZv2 entities which implement 
the XYZv2 MIB." 
MODULE -- compliance to the containing MIB module 
MANDATORY-GROUPS { xyzSystemGroup, 
xyzStatsGroup, xyzTrapGroup, 
xyzSetGroup, 
xyzBasicNotificationsGroup } 


GROUP xyzV1Group 
DESCRIPTION 
"The xyzVl group is mandatory only for those 
XYZv2 entities which also implement XYZv1." 
::= { xyzMIBCompliances 1 } 


According to this invocation, to claim alignment with the compliance 
statement named 


{ xyzMIBCompliances 1 } 


a system must implement the XYZv2-MIB’s xyzSystemGroup, 
xyzStatsGroup, xyzTrapGroup, and xyzSetGroup object conformance 
groups, as well as the xyzBasicNotificationsGroup notifications 
group. Furthermore, if the XYZv2 entity also implements XYZv1, then 
it must also support the XYZv1lGroup group, if compliance is to be 
claimed. 


6. Mapping of the AGENT-CAPABILITIES macro 


The AGENT-CAPABILITIES macro is used to convey a set of capabilities 
present in a SNMPv2 entity acting in an agent role. It should be 
noted that the expansion of the AGENT-CAPABILITIES macro is something 
which conceptually happens during implementation and not during run- 
time. 


When a MIB module is written, it is divided into units of conformance 
termed groups. If a SNMPv2 entity acting in an agent role claims to 
implement a group, then it must implement each and every object 
within that group. Of course, for whatever reason, a SNMPv2 entity 
might implement only a subset of the groups within a MIB module. In 
addition, the definition of some MIB objects leave some aspects of 
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the definition to the discretion of an implementor. 


Practical experience has demonstrated a need for concisely describing 
the capabilities of an agent with respect to one or more MIB modules. 
The AGENT-CAPABILITIES macro allows an agent implementor to describe 
the precise level of support which an agent claims in regards to a 
MIB group, and to bind that description to the value of an instance 
of sysORID [3]. In particular, some objects may have restricted or 
augmented syntax or access-levels. 


If the AGENT-CAPABILITIES invocation is given to a management-station 
implementor, then that implementor can build management applications 
which optimize themselves when communicating with a particular agent. 
For example, the management-station can maintain a database of these 
invocations. When a management-station interacts with an agent, it 
retrieves from the agent the values of all instances of sysORID [3]. 
Based on this, it consults the database to locate each entry matching 
one of the retrieved values of sysORID. Using the located entries, 
the management application can now optimize its behavior accordingly. 


Note that the AGENT-CAPABILITIES macro specifies refinements or 
variations with respect to OBJECT-TYPE and NOTIFICATION-TYPE macros 
in MIB modules, NOT with respect to MODULE-COMPLIANCE macros in 
compliance statements. 


6.1. Mapping of the PRODUCT-RELEASE clause 
The PRODUCT-RELEASE clause, which must be present, contains a textual 
description of the product release which includes this set of 
capabilities. 


6.2. Mapping of the STATUS clause 


The STATUS clause, which must be present, indicates whether this 
definition is current ("current") or historic ("obsolete"). 


6.3. Mapping of the DESCRIPTION clause 


The DESCRIPTION clause, which must be present, contains a textual 
description of this set of capabilities. 


6.4. Mapping of the REFERENCE clause 
The REFERENCE clause, which need not be present, contains a textual 


cross-reference to a capability statement defined in some other 
information module. 
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6.5. Mapping of the SUPPORTS clause 


The SUPPORTS clause, which need not be present, is repeatedly used to 
name each MIB module for which the agent claims a complete or partial 
implementation. Each MIB module is named by its module name, and 
optionally, by its associated OBJECT IDENTIFIER as well. 


6.5.1. Mapping of the INCLUDES clause 


The INCLUDES clause, which must be present for each use of the 
SUPPORTS clause, is used to name each MIB group associated with the 
SUPPORTS clause, which the agent claims to implement. 


6.5.2. Mapping of the VARIATION clause 


The VARIATION clause, which need not be present, is repeatedly used 
to name each object or notification which the agent implements in 
some variant or refined fashion with respect to the correspondent 
invocation of the OBJECT-TYPE or NOTIFICATION-TYPE macro. 


Note that the variation concept is meant for generic implementation 
restrictions, e.g., if the variation for an object depends on the 
values of other objects, then this should be noted in the appropriate 
DESCRIPTION clause. 


By definition, each object specified in a VARIATION clause follows a 
SUPPORTS clause which names the information module in which that 
object is defined. Therefore, the use of an IMPORTS statement, to 
specify from where such objects are imported, is redundant and is not 
required in an information module. 


6.5.2.1. Mapping of the SYNTAX clause 
The SYNTAX clause, which need not be present, is used to provide a 
refined SYNTAX for the object named in the correspondent VARIATION 
clause. Note that if this clause and a WRITE-SYNTAX clause are both 
present, then this clause only applies when instances of the object 
named in the correspondent VARIATION clause are read. 
Consult Section 9 of [2] for more information on refined syntax. 
6.5.2.2. Mapping of the WRITE-SYNTAX clause 
The WRITE-SYNTAX clause, which need not be present, is used to 
provide a refined SYNTAX for the object named in the correspondent 


VARIATION clause when instances of that object are written. 


Consult Section 9 of [2] for more information on refined syntax. 
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6.5.2.3. Mapping of the ACCESS clause 


The ACCESS clause, which need not be present, is used to indicate the 
agent provides less than the maximal level of access to the object or 
notification named in the correspondent VARIATION clause. 


The only value applicable to notifications is "not-implemented". 


The value "not-implemented" indicates the agent does not implement 
the object or notification, and in the ordering of possible values is 
equivalent to "not-accessible". 


The value "write-only" is provided solely for backward compatibility, 
and shall not be used for newly-defined object types. In the 
ordering of possible values, "write-only" is less than "not- 
accessible". 


6.5.2.4. Mapping of the CREATION-REQUIRES clause 


The CREATION-REQUIRES clause, which need not be present, is used to 
name the columnar objects of a conceptual row to which values must be 
explicitly assigned, by a management protocol set operation, before 
the agent will allow the instance of the status column of that row to 
be set to ‘active’. (Consult the definition of RowStatus [5].) 


If the conceptual row does not have a status column (i.e., the 
objects corresponding to the conceptual table were defined using the 
mechanisms in [6,7]), then the CREATION-REQUIRES clause, which need 
not be present, is used to name the columnar objects of a conceptual 
row to which values must be explicitly assigned, by a management 
protocol set operation, before the agent will create new instances of 
objects in that row. 


This clause must not present unless the object named in the 
correspondent VARIATION clause is a conceptual row, i.e., has a 
syntax which resolves to a SEQUENCE containing columnar objects. The 
objects named in the value of this clause usually will refer to 
columnar objects in that row. However, objects unrelated to the 
conceptual row may also be specified. 


All objects which are named in the CREATION-REQUIRES clause for a 


conceptual row, and which are columnar objects of that row, must have 
an access level of "read-create". 


SNMPv2 Working Group Standards Track [Page 19] 


RFC 1904 Conformance Statements for SNMPv2 January 1996 


6.5.2.5. Mapping of the DEFVAL clause 


The DEFVAL clause, which need not be present, is used to provide a 
refined DEFVAL value for the object named in the correspondent 
VARIATION clause. The semantics of this value are identical to those 
of the OBJECT-TYPE macro’s DEFVAL clause. 


6.5.2.6. Mapping of the DESCRIPTION clause 
The DESCRIPTION clause, which must be present for each use of the 
VARIATION clause, contains a textual description of the variant or 
refined implementation of the object or notification. 

6.6. Mapping of the AGENT-CAPABILITIES value 
The value of an invocation of the AGENT-CAPABILITIES macro is an 


OBJECT IDENTIFIER, which names the value of sysORID [3] for which 
this capabilities statement is valid. 


6.7. Usage Example 


Consider how a capabilities statement for an agent might be 
described: 


exampleAgent AGENT-CAPABILITIES 


PRODUCT-RELEASE "ACME Agent release 1.1 for 4BSD" 
STATUS current 
DESCRIPTION "ACME agent for 4BSD" 
SUPPORTS SNMPv2-MIB 
INCLUDES { systemGroup, snmpGroup, snmpSetGroup, 


snmpBasicNotificationsGroup } 


VARIATION coldStart 
DESCRIPTION "A coldStart trap is generated on all 
reboots." 
SUPPORTS IF-MIB 
INCLUDES { ifGeneralGroup, ifPacketGroup } 
VARIATION ifAdminStatus 
SYNTAX INTEGER { up(1), down(2) } 


DESCRIPTION "Unable to set test mode on 4BSD" 
VARIATION ifOperStatus 


SYNTAX INTEGER { up(1), down(2) } 
DESCRIPTION "Information limited on 4BSD" 
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SUPPORTS IP-MIB 
INCLUDES { ipGroup, icmpGroup } 
VARIATION ipDefaultTTL 
SYNTAX INTEGER (255..255) 


DESCRIPTION "“Hard-wired on 4BSD" 


VARIATION ipInAddrErrors 
ACCESS not-implemented 
DESCRIPTION "Information not available on 4BSD" 


VARIATION ipNetToMediaEntry 
CREATION-REQUIRES { ipNetToMediaPhysAddress } 
DESCRIPTION "Address mappings on 4BSD require 

both protocol and media addresses" 


SUPPORTS TCP-MIB 
INCLUDES { tcpGroup } 
VARIATION tcpConnState 
ACCESS read-only 
DESCRIPTION "Unable to set this on 4BSD" 
SUPPORTS UDP-MIB 
INCLUDES { udpGroup } 
SUPPORTS EVAL-MIB 
INCLUDES { functionsGroup, expressionsGroup } 
VARIATION exprEntry 
CREATION-REQUIRES { evalString } 


DESCRIPTION "Conceptual row creation supported" 
::= { acmeAgents 1 } 

According to this invocation, an agent with a sysORID value of 
{ acmeAgents 1 } 

supports six MIB modules. 

From SNMPv2-MIB, five conformance groups are supported. 

From IF-MIB, the ifGeneralGroup and ifPacketGroup groups are 


supported. However, the objects ifAdminStatus and ifOperStatus have 
a restricted syntax. 
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From IP-MIB, all objects in the ipGroup and icmpGroup are supported 
except ipInAddrErrors, while ipDefaultTTL has a restricted range, and 
when creating a new instance in the ipNetToMediaTable, the set- 
request must create an instance of atPhysAddress. 


From TCP-MIB, the tcpGroup is supported except that tcpConnState is 
available only for reading. 


From UDP-MIB, the udpGroup is fully supported. 

From the EVAL-MIB, all the objects contained in the functionsGroup 
and expressionsGroup conformance groups are supported, without 
variation. In addition, creation of new instances in the expr table 
is supported. 


7. Extending an Information Module 


As experience is gained with a published information module, it may 
be desirable to revise that information module. 


Section 10 of [2] defines the rules for extending an information 


module. The remainder of this section defines how conformance 
groups, compliance statements, and capabilities statements may be 
extended. 

7.1. Conformance Groups 


If any non-editorial change is made to any clause of an object group 
then the OBJECT IDENTIFIER value associated with that object group 
must also be changed, along with its associated descriptor. 


7.2. Compliance Definitions 


If any non-editorial change is made to any clause of a compliance 
definition, then the OBJECT IDENTIFIER value associated with that 
compliance definition must also be changed, along with its associated 
descriptor. 


7.3. Capabilities Definitions 


If any non-editorial change is made to any clause of a capabilities 
definition, then the OBJECT IDENTIFIER value associated with that 
capabilities definition must also be changed, along with its 
associated descriptor. 
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8. 


10. 


Security Considerations 
Security issues are not discussed in this memo. 
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